home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
SPACE 1
/
SPACE - Library 1 - Volume 1.iso
/
program
/
569
/
rsctools
/
rmerge.man
< prev
next >
Wrap
Text File
|
1992-06-01
|
14KB
|
241 lines
RMERGE ST Programmer's Manual RMERGE
NAME
rmerge - selectively merges GEM resource files
DESCRIPTION
Rmerge is a utility designed to facilitate merging of GEM resource
files. Existing resource construction programs provide this
capability only to a very limited degree; in particular, they tend
not to preserve tree and object names when copying an entity from
one file to another, making it very difficult to share resource
files or maintain a resource file "library." In addition, most
editors are limited to editing one file at a time; although they
provide a clipboard for inter-resource file pasting, the clipboard
can hold only one tree at a time, so that copying multiple trees
involves loading, saving, and reloading and resaving of the resource
files. Rmerge was written to address these problems and make
resource file merging as effortless as possible.
Rmerge is a GEM program that takes no command line options. When run,
rmerge presents the file selector; enter the name of a resource file
you wish to merge. As long as Cancel wasn't pressed, rmerge presents
the file selector a second time; enter the second resource file to
merge, or just press Cancel to proceed with the program. After the
"source resource file(s)" have been designated, rmerge displays its
main dialog box.
Note: rmerge understands the four definition file formats known to
the author: DEF (DRI RCS 1), DFN (DRI RCS 2), RSD (Kuma/MWC), and
HRD (Wercs). At least one file having the same basename as the
resource file and ending with one of these extensions must be
present in the same directory as the resource file; rmerge will
otherwise abort. If more than one definition file is present,
rmerge will inform you and present the file selector, so that you
may choose the definition file rmerge will use.
The main rmerge dialog contains three scrollable lists. The two
leftmost lists contain the tree-level (i.e. dialogs, panels, menus,
free strings, alerts, and free images) item names for the source
resource files, while the rightmost list contains the tree-level
names for the merged or target resource file, and this list is
initially empty. The "Show" radio buttons control which group of
names rmerge will display at any given time.
Now, consider the four buttons in the lower right corner of the
rmerge dialog. The "Copy" and "Replace" buttons act upon selected
items in the two source lists; after selecting some source items
and pressing Copy, for example, the item names appear in the target
list. The "Remove" button removes selected items from the target
list. The "Copy All" button requires no selected items; rather, it
duplicates either the first or second resource file in the target
file. Copy All should only be used when the target resource is
empty; otherwise, name conflicts are very likely to occur, causing
the operation to be aborted.
Copy and Replace differ in how they deal with name conflicts. As
mentioned earlier, rmerge preserves names when constructing the target
resource, and duplicate names are not allowed. When merging trees into
the target, a name conflict may occur in the tree name and also among
the objects comprising the tree and any other names currently in the
target. Rmerge identifies both types of conflicts. Copy aborts upon
finding any name conflicts, while Replace may or may not, depending
on the type of the conflict. If Replace discovers the item name is
duplicated within the same item class (e.g. a dialog-menu conflict),
it will proceed to replace the target item with the source item.
If, on the other hand, Replace discovers an inter-class conflict, such
as a dialog-free image mismatch, it will report the error and abort
the operation. When working with trees, Replace will still report an
error if it discovers a conflict between an object name within the source
item and any names currently in the target, unless the conflict is in
the item being replaced. When the item doesn't already appear in the
target resource, Replace acts like Copy.
Copy and Replace both copy all selected items in the first source
resource before starting on the selected items in the second. Copy
always appends items to their respective classes.
After constructing the target resource, click "Save" to save the new
resource file. Rmerge presents the file selector, and after the filename
has been chosen, rmerge presents an alert box allowing a choice of
definition file formats. After the definition file format is chosen,
rmerge saves the resource file, definition file, and C header file;
the latter two filenames are built from the target resource file
basename and the appropriate extensions.
Note: one of the more frustrating aspects of working with resource
files is the need to recompile entire programs when the tree-level
structure of the resource file changes. For example, if one deletes
a tree, the indexes of the trees following it in the resource file
all change by one, and the program must be recompiled. Rmerge can't
do anything about this; however, under some circumstances one can
avoid a global recompile. Specifically, if using rmerge to add some
trees to an existing resource, as long as the new trees are added to
the target _after_ the existing resource has been duplicated in the
target via "Copy All", only those files dependent on the new trees
need be recompiled. Similarly, if a tree in the target is _replaced_,
only those modules dependent on that tree need be recompiled.
EXAMPLES
Example 1
Suppose two programmers are working on a project and sharing the
resource file; programmer 1 adds some trees to the resource, and
programmer 2 would like to update his idea of the resource to
conform to programmer 1's. The merge process would proceed as
follows:
Step 1: programmer 2 loads his idea of the resource as the first
source resource and programmer 1's as the second,
Step 2: he then clicks "Copy All", selecting the "1" button in the
alert box that is presented (this copies his idea of the resource
in its entirety to the target),
Step 3: he then identifies the new trees in programmer 1's resource,
selecting them in the scrollable list, and clicks "Copy"; two
possibilities exist:
a. a "name conflict" alert will appear, indicating that the
two progammers have accidentally used duplicate names,
in which case they need to agree on a solution and correct
the problem with the resource construction program,
b. the operation will silently succeed.
Step 4: he saves the merged resource and quits rmerge.
Step 5: he compiles any files dependent on the new trees; since
he used "Copy All" and _added_ trees, free strings, etc., the
tree-level structure of the resource doesn't change, as far as
his earlier code is concerned.
Example 2
Assume the scenario in example 1, except that programmer 1 modifies
some _existing_ trees. Programmer 2 would follow the same steps as
given above, except that he would click "Replace" in Step 3 rather
than "Copy", because Replace allows name conflicts between a tree
and its objects and the tree and objects it's replacing. Note,
however, that if the source tree contains other name conflicts, say
between one of its objects and a free image or an object in another
tree, Replace will correctly abort the operation, and the resource
editor is required to resolve the conflict. Step 5 also changes;
the programmer must recompile any modules dependent on the trees
that were _replaced_; modules dependent upon unaffected trees
needn't be recompiled.
Example 3
A programmer has designed a resource file containing some trees
he wishes to use in a new application. He would simply load the
existing resource into rmerge, foregoing loading the second source
resource, copy everything he wishes to reuse to the target resource,
and save the new resource. Since he can selectively transport
items to the target resource, this is significantly easier than
using a resource editor (the equivalent process in the latter type
of program would require deleting everything he _doesn't_ want,
rather than including everything he _does_, because resource editors
don't preserve item names).
Example 4
A programmer has a resource built with the DRI editor, and he now
wishes to use the Kuma editor. He can translate the definition file
from DFN to RSD by loading the file into rmerge, clicking Copy All,
and saving the new file, choosing the Kuma (RSD) definition format.
NOTES
The Kuma/Mark Williams resource editor treats TEDINFOs differently
from the other editors known to the author. Specifically, it pads
the `te_ptext' fields with zeros so that they are at least as long
as their corresponding `te_pvalid' fields, presumably as a safeguard
against overflowing the array when operating the form, despite the
common practice of patching the structures at run-time with larger
arrays. Thus when saving a target resource for the Kuma definition
file format, rmerge follows this (undocumented) convention.
Rmerge was built using a custom interface library. All the buttons
in the dialog box have associated hotkeys, indicated by underline
or color. To select a button from the keyboard, press Alt plus the
highlighted character, or since the dialog contains no edit fields,
just press the character itself (Alt isn't required unless edit
fields are present). Esc/Undo select the "Cancel" action, when
appropriate. The scrollable lists support continuous selection while
scrolling. Shift-clicking selects an item when one or more items is
selected, adding the item to the group of selected items. Control-Alt-
clicking a list item selects every item in the list.
The File Selector provides a number of improvements on the GEM file
selector. For one, you can navigate directories as you would in a
command line shell, typing things like "..\cli", "e:", and "c:\auto"
followed by pressing Return. You can also enter wildcard specifications
in the same manner, and wildcards act much like they do under Unix
systems. You can use character classes as in "a*[a-z][^aeiou]?";
"*" matches every file, "*.*" matches only files with extensions, and
"*." matches only files without extensions. Unlike with TOS, wildcards
such as "*f*" are meaningful, and the dot in a filename isn't treated
specially, except that a "?" won't match it, and the "xxx." pattern
matches files without extensions. Of course, you can always enter
a more or less fully qualified path for the filename you wish to select
in the edit field; as long as it doesn't contain wildcard characters
and isn't a directory, the File Selector will return the filename to
the caller. Sometimes a list of extensions is provided on the right
side of the File Selector; click on any one of these to replace the
current extension. Clicking an already-selected extension button
removes the extension from the current filemask; double-clicking an
already-selected extension button removes the extension but leaves the
dot. Double clicking an already-selected drive button forces a media
change on that drive. You can back up to parent directories by clicking
the ".." entry at the top of the directory list, typing "..", or by
clicking on the desired directory name in the "Path" line. Clicking the
current directory name in "Path" copies the entire path to the edit
field, while clicking the filemask portion copies only the mask.
Although rmerge has no use for this feature, depending on how it's
called, the File Selector can return multiple files to the caller.
AUTHOR
Doug Harrison
Electronic mail:
GEnie: D.S.HARRISON
Bix: dharrison
Compuserve: 72277,2315
U.S. Mail:
Doug Harrison
P.O. Box 66236
Baton Rouge, LA 70806-6236
Please send any comments and criticisms to any of the above
addresses. Shareware donations cheerfully accepted! (see the
accompanying README.TXT file for details on this and distribution
instructions)